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A SYSTEM AND METHOD FOR INTELLIGENT 
5 NETWORK SERVICES 

The present invention relates to a call processing method and a network system, which 
are particularly, but not exclusively, useful in executing Intelligent Network (IN) services which 
may be provided across a number of different telecommunications networks. 

IN services, such as call forwarding, call diversion and messaging services, are provided 
in fixed telecommunication networks by a traditional structure which has dedicated IN computer 
logic for each network and which is common across all switching nodes of the network to 
service those nodes. The nodes, normally located in exchanges of the network, act as Service 

1 5 Switching Points (SSPs) which can be triggered on a characteristic of an incoming or outgoing 
call to send data associated with the call to a Service Control Point (SCP) of the computer logic 
to process an IN service. The SCP determines how the service is to be processed and may need 
to access data at a Service Data Point (SDP) of the logic in order to execute the service. The 
SCP then feeds the required information back to the SSP to complete execution of the service 

20 and direct the call handled by the SSP appropriately. The IN computer logic is normally held 
in one central location for its respective network, and all IN services need to be processed at that 
central location. Mobile telecommunications networks, such as GSM, AMPS and CDMA 
networks are also able to execute IN services respectively, such as messaging services. The 
mobile networks however do not rely on discrete and separate IN computer logic for each 

25 network, but instead rely on computer logic which is built into the components of each network, 
such as the Base Station Controllers (BSC) and the Mobile Switching Centres (MSC). All of 
the networks execute their own respective communication protocols to access IN service data 
and execute IN services. 

30 It is desired to provide a method or system which enables IN services to be delivered 

efficiently across a number of telecommunications networks, and which alleviates the 
restrictions imposed by the existing network specific architectures and processes described 
above, or which at least provides a useful alternative. 
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In accordance with the present invention there is provided a call processing method, 
including: 

processing characteristic data associated with a communications call at a network switch 
to determine if intelligent network (IN) service data is required to establish said call; 
5 passing said characteristic data to a network service data gateway when said service data 

is required; 

processing at least part of said characteristic data by said gateway to determine a network 
location to access in order to obtain said service data, and a communication protocol for 
connecting to said network location; and 
10 obtaining said service data and passing said service data to said switch to establish said 

call. 

The present invention also provides a network system having: 

a network switch for processing characteristic data associated with a communications 
1 5 call to determine if Intelligent Network (IN) service data is required to establish said call; 

a network service data gateway for receiving said characteristic data from said network 
switch when said service data is required, said gateway being adapted to process at least part of 
the characteristic data to determine a network location to access in order to obtain said service 
data, and a communication protocol for connecting to said network location; and 
20 wherein said gateway is adapted to receive said service data and pass the service data 

to said switch to establish said call. 

Preferred embodiments of the present invention are hereinafter described, by way of 
example only, with reference to the accompanying drawings, wherein: 
25 Figure 1 is a schematic diagram of a preferred embodiment of a network system; 

Figure 2 is a schematic diagram of part of the network system providing voice messaging 
services; 

Figure 3 is a block diagram of part of the network system providing IN terminating 
services; 

30 Figure 4 is a block diagram of the network system; 

Figure 5 is a block diagram of part of the network system performing mobile terminated 
SMS policing; 

Figure 6 is a block diagram of the network system performing mobile originated SMS 
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policing; and 

Figure 7 is a block diagram of part of the network system providing local switching 
access for a private network. 

T**s ft S) 

5 An intelligent network system 2, as shown in Figure 1, is able to process IN service 

requests and, in particular, handle a range of mobile originating IN services, such as access to 
messaging services, as well as a range of terminating IN services. The system 2 includes a 
plurality of telecommunications networks 4 to 12 and private networks 14 or stations 16 which 
are able to communicate with an IN gateway 20 for the provision of IN service data. The 
10 telecommunications networks including foreign networks 4, a local intelligent switching 
network 6, such as the PSTN, and mobile networks, such as a CDMA network 8, an AMPS 
network 10, and a GSM network 12. The gateway 20 can also communicate with Base Station 
Systems (BSS) of an office network 14 or a private home 16. 

15 The gateway 20 of the system 2 has computer logic 22 which is configured to 

communicate with the networks 4 to 14 and the BSS 16 using the respective communication 
protocols for the networks 4 to 14 and the BSS 16, and is also able to respectively poll for IN 
service data requests from the networks 4 to 14 and the BSS 1 6. The system 2 provides a central 
"home" layer and a "visitor" layer by having a central Home Intelligent Network (HIN) 24 

20 which maintains central IN service data and a plurality of Visitor Intelligent Networks (VINs) 
26 which are distributed amongst at least the local networks 6 to 14 and the BSSs 16 which the 
IN system 2 needs to serve. The VINs 26 each include the computer logic 22 and act as the 
gateway 20 for communicating with the networks 4 to 14 and the BSSs 16. The VIN logic 22 
is able to communicate with the HIN 24, using INAP or TCP/IP, to obtain IN service data 

25 information. For example, an IN service data request may be triggered in one of the switching 
nodes of the networks 4 to 12 in order to enable the node to process a call request. The IN 
service data request may have been triggered by the node on the basis of the called number, the 
called number and the calling number or categories of the A or B parties associated with the 
call. The service request is received by the VIN logic 22, which initially will refer to the HIN 

30 24 concerning the requests. The HIN 24 maintains a customer database 28 which maintains 
simple look up tables for customers or subscribers and an IN service database 30 to process IN 
service data requests associated with more complex IN services, such as sophisticated call 
diversion and Virtual Private Networks (VPNs). The customer database 28 may provide service 
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data such as which network the call relates to and an address within that network where further 
information on the B party can be obtained. The IN service database 30 may provide complete 
service data on how to establish the call together with billing information. The service data is 
fed back to the requesting node via the VIN logic 22 which stores a copy of the service data in 
5 a local cache for subsequent similar requests. Caching of the data by the VIN 26 allows a large 
number of local IN service data requests to be processed without referring to the HIN 24, 
therefore significantly saving on network resources. Therefore whilst the HIN 24 functions 
primarily as an SDP and the VIN 26 as an SCP, the HIN 24 also acts as an SCP and the VIN as 
an SDP, contrary to traditional IN architectures. 

10 

The IN system 2 provides, as described in more detail below, the following: 

(i) home and visitor based management of IN service data and control logic. 

(ii) customer independence from the terminating IN service, the terminating network 
and the final terminal. 

1 5 (iii) protocol independence from the terminating network. 

(iv) private network access to public mobility data. 

(v) terminal network selection. 

(vi) policing of messages from other networks, such as international networks. 



20 For traditional mobile networks, such as a GSM network 12, mobility related data 

follows a customer or subscriber as they change their servicing Mobile Service Centre (MSC) 
when moving from one part of the network to another. The IN system 2 in its home and visitor 
management of IN data maintains VINs 26 for respective regions or areas, but only transports 
IN data to the VINs 26 from the HIN 24 when an IN service is invoked. The data sent from the 

25 HIN 24 to a VIN 26 is cached locally in the VIN 26 for a predetermined period of time, such 
that if the IN service is invoked again within that period, the data can be provided locally from 
the VIN 26 to a local switch 32, without accessing the HIN. If customer data is changed in the 
HIN 24 all of the relevant VINs 26 containing a copy of the data are updated by the system 2. 
Data changes in the HIN 24 can be initiated by a subscriber using a VIN 26 or directed directly 

30 to the HIN 24. The predetermined period for data retention by a VIN 26 may be one or two days. 

An example of Originating IN Service (OINS) management by the system 2 is 
processing of a voice message service request, as shown in Figure 2, where a customer in Perth 
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dials 101 to access any stored messages. The call request is received by a switch 32 located in 
Perth which on processing the called number sends an IN service data request to a VIN 26 
located in Perth. The service data request includes the calling and called numbers so the 
customer can be identified. If the relevant IN service data is not cached within the VIN 26, the 

5 VIN contacts the HIN 24 to obtain the hidden address for the customer's mailbox. This address 
is then cached in the VIN 26 and passed back to the switch 32 with data instructing the switch 
32 to direct the call to the voice message service database 36. The switch 32 establishes the call 
to the database 36 and passes the hidden address to the database 36 to enable the customer to 
access his/her mailbox. On flying to Melbourne, the IN service data which enables the customer 

10 to access his/her mailbox in the database 36 is only transferred to the VIN 26 in Melbourne 
when the customer makes a call to the mailbox by dialling 101 . The VIN 26 in Melbourne will 
then execute the same service to obtain the mailbox data, which it then retains in its local cache 
for subsequent mailbox requests. 

15 For Terminating IN Service (TINS) management, the network system 2 in processing 

a request to establish a call is able to forward appropriate terminating IN script, as described 
below, from the HIN 24 to a VIN 26, and then provide the terminating script to a local switch 
32 or 34 which is used to establish the call. The script may forward the call to another network, 
implement a mobile technology specific operation or invoke a particular IN service at the 

20 terminating end. The mobile specific operation may be obtaining a "Roaming" number or 
executing a "Call Screening" function when a user is roaming overseas. 

The network system 2 provides network and terminal independence for a customer 
because the data which is held for each customer by the HIN 24 is accessible by all of the 

25 telecommunication networks 4 to 14 and BSSs 16 using the HIN/VIN architecture. The data 
maintained by the HIN 24 for each customer includes data on what network the customer 
belongs to, the type of technology associated with the network, where further data on the 
customer can be obtained, such as the location of a Home Location Register (HLR) and what 
terminal identity, i.e. terminal number, to use. Data on additional IN services associated with 

30 the customer may also be included, which may require more than one network to be contacted 
before a call to the customer can be established. Customers associated with different networks 
can have priorities assigned to the networks for establishing a call to the customer. The HIN data 
may also specify an appropriate messaging service to be contacted if a customer cannot be 
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located on one or more networks. 

For example, a customer may have a mobile terminal 40 allocated a terminating number 
0418 123 456, and whilst the customer has the terminal 40 switched on in Brisbane, as shown 
5 in Figure 3, location data is copied into a Visitor Location Register (VLR) 44 of the MSC 42 
in Brisbane and the GSM HLR database 46, in accordance with standard GSM network 
procedures. A caller 48 on the PSTN 50 in Perth placing a call to the customer dials the 
customer's number which is passed to the switch 32 in Perth for processing. The switch 32 
contacts the VIN 26 in Perth using the ATUP, ISUP or INAP protocols and asks the VIN to 

1 0 forward IN service data to it so it can establish the call. The VIN 26 contacts the HIN 24 using 
INAP to obtain data on the customer on the basis of the terminating number. Using the number, 
the HIN 24 accesses data to determine on which network 4 to 14 the customer resides and where 
the VIN 26 can access further data on the customer's location. For a GSM customer, the HIN 
24 provides data back to the VIN 26 specifying the address for the GSM HLR 46 the VIN 26 

15 needs to contact and also advising the VIN 26 that it needs to use the MAP protocol to 
communicate with the HLR 46. The VIN 26 then contacts the HLR 46 to obtain the location of 
the customer, and in particular a GSM roam number which can be used to route the call to the 
customer. This data is then forwarded to the switch 32 by the VIN 26. The switch 32 then uses 
the roam number to route the call from the caller 48 to the MSC 42 and onto the terminal 40. 

20 Similar processing occurs if a caller 52 on a mobile network in Melbourne places a call to the 
terminal 40, with the call being processed and established by the VIN 26 and the switch 34 in 
Melbourne. The architecture of the network system is particularly advantageous as it provides 
one gateway 20 for use in terminating all mobile network calls for different networks 8 to 12, 
without requiring reference or reliance on gateways which are specific to each mobile network 

25 8,10 or 12. Once calls to the terminal 40 are completed, the VINs 26 retain their local cache 
data specifying that the terminal 40 is a GSM terminal, the HLR 46 which needs to be contacted 
for a roam number and the protocol, MAP, which needs to be used. 

The network system 2 provides technology independent processing of IN services by 
30 having a generic IN service front end in the VIN 26, which uses standard protocols such as 
ATUP, ISUP or even INAP to communicate with a front end local exchange switch 32, such as 
an MSC, depending on the protocol used by the switch 32, as shown in Figure 4. The computer 
logic 22 of the VIN 26 translates the generic protocol service requests from the switch 32 into 
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a back end technology specific transaction according to a customer's IN script which it obtains 
from the HIN databases 28 and 30 or which may already be stored in the VINs local cache 23. 
The IN script specifies the specific communication protocol to be used to obtain IN service data 
from technology specific network equipment 54. For example, the VIN logic 22 can 
5 communicate using IS41 with an HLR 56 of a CDMA network 8, MTUP to communicate with 
an HLR 58 of an AMPS network 10, and MAP or INAP to communicate with an HLR 46 of a 
GSM network 12. The VIN 22 may also need to use INAP, on instructions from the HIN 24 to 
contact an INAP based IN 60 to obtain specific call routing information or IN service data or 
to connect with an intelligent network peripheral. An IN service data request to the VIN 26 will 
1 0 normally be triggered within a switch 32 on processing a call based on the called number, the 
called number and the calling number, or categories or ranges associated with A or B parties or 
both for a call. The VIN 26 then processes the IN service data request so as to establish the 
service data required by the switch 32, which as discussed, may be obtained directly from the 
HIN 24 or may involve contacting different network technology specific equipment 54. 

15 

The network system 2 determines which network 4 to 12 should be used to originate a 
call when more than one network is available for a terminal. The occurs when the terminal is 
one of the following: 

(a) a multimode terminal where both modes are available at all times, and is referred 
20 to as a parallel mode terminal. 

(b) a multimode terminal where only one mode is available at any given time, and 
is referred to as a dual mode terminal. 

(c) a single mode terminal which can access different network layers of a network. 
This covers radio layering which may be used when not all services are offered 

25 on all network layers. 

(d) a single mode terminal which can access only one network but the network can 
be switched between private and public modes. 

The network system 2 enables the appropriate operating mode for the terminals to be 
30 selected, either using terminal based selection, network prompted terminal selection or network 
selection, as described below. 



Terminal based selection can be used in multimode terminals which can be set to select 
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different networks depending on the type of call made, e.g. voice, fax, data or messaging 
service. For example, a dual mode terminal operating with a Cordless Base Unit (CBU) 1 6 can 
be connected to the CBU 16 or a mobile network 8, 10 or 12. The terminal would be set to send 
certain calls via the mobile network, such as fax and data calls, and other calls via the CBU. 
5 When the CBU is busy, the terminal can send calls via the mobile network 8, 10 or 12, and will 
be handled by the gateway 20, which may apply a discount call tariff if the gateway 20 can 
confirm the terminal is in the coverage area of the CBU, i.e. the terminal is "at home' 5 . 

For network prompted terminal selection, the VIN 26 provides via the switch 32 
10 instructions to a terminal regarding a choice of networks to use for originating a call. The VIN 
26 provides messages detailing networks to be attempted in a priority based order. 

For network selection, the VIN 26 retrieves service data in order to make a decision for 
a switch 32 and ultimately the terminal connected to it, as to which network should be used 

15 based on either the terminal identity, the requested service or the requested destination. For 
example, in a private wireless office environment, calls destined to the PSTN may be switched 
locally in the office, whereas public and private users requesting services only supported on the 
public mobile network, such as SMS, fax and data services, and private users requesting voice 
IN services only available on the public mobile network, such as voice message services, would 

20 all have their calls switched back through the public mobile network. 

The network system 2 is also able to perform SMS policing and in particular can apply 
it to policing of international SMS traffic. 

25 Policing of mobile terminated SMS traffic coming into a local network can protect local 

customers from unwanted SMS traffic originated by a foreign network 4. Policing is achieved 
by having all international MAP traffic destined to local network HLRs 46, 56 and 58 routed 
through a VIN 26, as shown in Figure 5. All SMS traffic except the MAP SMS Send Routing 
Information (SRI) message to the local HLR 46 is passed transparently. The SRI messages are 

30 screened by the VIN 26 to determine the originating global title address of the Short Message 
Service Centre (SMSC) and the destination mobile. SRI messages that are not on a bar list are 
passed to the appropriate HLR 46, and acknowledged with an SRI_ACK message as usual, 
whereas SRI messages that are barred are returned to the SMSC with a request rejected message 
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SRI_NAK generated by the VIN 26. 

Incoming mobile originated SMS policing can protect local SMSCs from unwanted SMS 
traffic originated in foreign networks 4, as well as providing a mechanism for load sharing 
5 between the SMSCs 70 of the local network 12. The MAP Forward Short Message (FSM) 
messages generated by a mobile terminal 40 are passed via VIN 26 to SMSC 70 of a local 
network 12 to determine if the traffic is allowed to pass, and if so, to which final service centre 
address the traffic should be sent to. The decision to enable the traffic to proceed to the network 
12 is based on analysis of the originating foreign network 4, the originating terminal address, 

10 and the destination SC address. Following the analysis, only customers of the local network 12 
roaming overseas may be allowed to originate and send traffic to an SMSC 70, and the network 
system 2 can distribute the messages evenly to all SMSCs 70 of the local network 12. Messages 
passed are acknowledged with an FSCM_ACK signal back to the mobile from the SMSC 70 
via a VIN 26, otherwise if a message is refused, the VIN 26 generates an FSCM_NAK signal 

1 5 for the mobile 40, as shown in Figure 6. 

Similarly, outgoing mobile originated SMS destined for foreign networks can be policed 
to determine foreign networks 4 and the foreign SMSCs 72 which local customers are allowed 
access to from a carrier's network including the system 2. The VIN 26 may refuse to pass FSM 
20 traffic based on the identity of the terminal 40 originating the message, the destined network 4 
or the destination SC address of the SMSC 72. Appropriate FSCM_ACK and FSCM NAK 
signals will be passed back to a mobile terminal 40 via the local network 12. 

Local switching access to mobility data is provided for a private network 14, as shown 
25 in Figure 7. 

Many modifications will be apparent to those skilled in the art without departing from 
the scope of the present invention as herein described with reference to the accompanying 
drawings. 

30 



